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The  TARDEC  Systems  Engineering  Lean  Process  Model  is  a  synthesized  version  of  the  DAU  SE  Process  model 
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A  way  of  depicting  the  interactions  among  Technical  Processes  and  their 
controlling  Technical  Management  Processes  is  shown  here  as  the  'Systems 
Engineering  Engine'. 
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Technical  Processes  get  applied 
recursively  to  each  system  element, 
from  the  top  to  the  bottom.  This 
continues  until  the  lowest  system 
products  are  defined  to  the  point 
where  they  can  be  implemented 
(i.e.,  bought,  built  or  reused)  cmd 
realized. 

Meanwhile,  Technical  Management 
Processes  are  controlling  all  these 
Technical  Processes  and  ensuring, 
their,  effective  application. 
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Establish  Requirements  Baseline 


IRG  content  includes  flow  maps,  and 
process  attachments  with  standardized 
process  descriptions: 

Process  Guidance: 

Tool  Guidance: 

Inputs: 

Mechanisms: 

Tasks: 

Outputs: 

Documentation  Guidance: 

Review  Guidance: 

Role  Guidance : 

TARGET/CT  Question  Guidance 
Example  thread  Guidance: 


Additional  attachments  with  relevant 
process  material ,  such  as  training 
documents,  will  also  be  included. 


Level  1  Process  Flow  -  Requirements  Example 


Requirements 

Establish  System  Requirements  Baseline 
(Stakeholder  Definition.  Requirements  Analysis) 


Process  Flows  Also 
Have  Sub  Levels 


IDEF  Diagrams:  Contain  Inputs  to  Process  Elements  Along 
with  Process  Tasks,  Process  Outputs  and  Mechanisms 


Process  Inputs: 

Project  Scope:  Project  scope  includes  a  clear 
statement  of  the  problem  to  be  solved. 

Stakeholder  Knowledge:  Stakeholders  are 
source  of  requirements  and  contextual 
information  that  is  essential  to  fully  understand 
the  problem  to  be  solved  and  to  formally  define 
success. 

Systems  of  Systems  Views:  System  of 
Systems  views  include  graphical  views  or 
tables  that  provide  context  by  illuminating 
where  the  system  fits  into  a  System  of  Systems 
or  how  the  system  interacts  with  legacy 
systems. 
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IDEF  Diagrams:  Contain  Inputs  to  Process  Elements  Along 
with  Process  Tasks,  Process  Outputs  and  Mechanisms 


Process  Outputs: 

Context  Diagram:  At  a  minimum,  a  System 
Context  Diagram  identifies  each  interface  with 
an  external  system.  External  interactions  may 
be  labeled  by  type:  functional,  control,  data, 
mechanical,  etc. 

(example  next  page) 

Top  Functions:  The  top-level  functional  model 
of  a  system  may  be  a  simple  2  or  3  level 
hierarchical  decomposition  of  the  functions  that 
a  system  must  support. 

Top  level  architecture  model:  The  top-level 
architectural  model  of  a  system  may  be  a 
simple  2  or  3  level  hierarchical  decomposition 
of  the  hardware/software  subsystems,  user 
tasks  and  data  stores/elements  that  comprise 
the  system. 
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Process  Guidance  Descriptions:  Are  Included  with  Each 
Process  Element  and  Address  S&T  as  Well  as  Acquisition 
Program  Use  Case  Scenarios 


Process  Guidance 
Type 

IRG  Process  Content 

Review  Guidance 

Explain  how  the  outputs  of  this  function  will  be  used  during  a  Technical  Review  event. 

Role  Guidance 

Describe  who  in  the  organization  (by  role)  is  responsible  for  supporting  this  function. 

Tool  Guidance 

Describe  what  SE  tools,  such  as  DOORS,  are  used  to  support  this  function. 

Documentation 

Guidance 

Describe  how  a  knowledge  pattern  or  document/report  template  should  be  used  to  support  this 
function. 

WBS  Guidance 

Explain  how  this  process  (and  its  children)  should  be  mapped  to  a  project  WBS,  i.e.  translated  into 
executable  tasks. 

Example  Thread 
Guidance 

Include  diagrams,  screen  shots  or  textual  descriptions  of  examples  of  this  function  being  performed 
or  its  outputs. 

TARGET/CT  Question 
Guidance 

Capture  all  relevant  questions  contained  in  the  SE  Capability  Tool  (CT)  that  relate  to  mapping  this 
function  to  the  TARGET  development  cycle. 
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References  and  Additional  Guidance 


Please  contact  the  Systems  Engineer  assigned  to  your 
project  for  further  guidance 


Detailed  Process  information  on  the  TARDEC  Systems 
Engineering  Process  can  be  accessed  from  the  Systems 
Engineering  Homepage  via  the  TARDEC  Portal 


Systems  Engineering  Group  Homepage 

https://poital2.tacom.army.mil/sites/tardec/ebg/systennsengineeriiig/pages/default.aspx 

CLICK  on  Interactive  Reference  Guide  (IRG)  Icon 


